Sumo Logic – LogReduce、LogCompare の用途は？例を交えてご紹介！

LogReduce、LogCompare の検索用途について解説しました！

#SIEM

#Sumo Logic

佐久間昇吾

2023.03.16

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

結論

Sumo Logic では、LogReduce、LogCompare という特許技術を用いた検索機能により、ログのクラスタリングが可能です。
今回は、それぞれの違いと効率的な検索方法について、想定されるユースケースをもとに例を交えながら解説していきます。

LogReduce、LogCompare とは？

そもそも、LogReduce と LogCompare は、それぞれどんな機能で、どんな効果をもたらすのかを解説します。

LogReduce

ログのクエリ結果で出力される文字列パターンをもとに類似性でグループ化してくれる AI 基盤の機能です。
これにより、少量にグループ化されたログを調査することが出来ます。

LogReduce | Sumo Logic

LogCompare

LogReduce をベースに、過去データとの比較を行ってくれる機能です。
それぞれ、グループ化されたログデータと、現在のログデータを比較して、グルーピングします。LogCompare では、新たなログの排出や、増減の傾向も知ることが可能です。

LogCompare | Sumo Logic

LogReduce、LogCompare の共通する使用方法

両方とも、LogSearch でクエリ検索する前、もしくはした後に使用可能です。

検索する時

_sourceCategory=* // 任意のメタデータ、カテゴリデータを指定可能
| LogCompare

下記のように途中まで入力すると候補も出ます。

検索した後

下記、どちらかのボタンを選択するだけです。

前提としての概要は蓄えましたので、ここから先は、それぞれの具体的な違いや、ユースケースに触れていきます。

LogReduce

冒頭にご紹介したグループ化についてもう少し詳しくご説明します。 LogReduce を使用して、グループ化された類似のログ群は Signature という項目にまとめられます。さらに、Sumo Logic は、Count という項目に類似グループのログ数を表示し、ユーザは、Signature ごとの詳細なログメッセージを見ることが出来ます。また、Signature には、ログが表示されずに Others と表示されることもあります。これは、重要度の低い単純なメッセージが含まれるため、グループ化できないことを意味します。

それでは、ここから LogReduce の構文を読み解き > 注意点を踏まえ > ユースケースをご説明します。

構文

| logreduce [field] [by] [limit] [, criteria]

構文を読み解くと、[field] [by] [limit] [, criteria] と４つの要素を使用して検索できることが分かります。下記、要素の解説です。

[field]

グループ化するフィールドを指定します。フィールドが指定されてない場合は生のメッセージを使用します。

具体的には、purse や、json 演算子で解析したログのフィールドを指定できます。しかし、| logreduce [field] だけではあまりメリットがないです。もし、[field] を指定するのであれば、後述の by などと併用してみてください。

[by]

LogReduce で作成されるグループに対して何かしら別の要素でグループ化したいときに使用します。

具体的には、Field や、_timeslice などです。しかし、この場合は count 演算子と同じようにデータを集計するだけで、Signature を調査できません。

// Field
_sourceCategory=Labs/Apache/*
| parse "GET * " as Get_Object 
| logreduce by Get_Object

// _timeslice
_sourceCategory=Labs/Apache/*
| parse "GET * " as Get_Object
| timeslice 1m
| logreduce(Get_Object) by _timeslice
| sort by _timeslice asc

[limit]

返される署名の数を制限します。

LogReduce は基本的に多くのログを処理します。そのため、Signature の数も多くなるのですが、それだと調査が難しい場合に Signature の数を制限します。

_sourceCategory= "Labs/AWS/GuardDuty_V8"
| logreduce by _sourceHost limit=5

[, criteria]

LogReduce はデフォルトで最も異常な Signature を検出します。この基準を criteria でオーバーライドします。

criteria=mostcommon // 最も頻繁に出現するカウント数の多い Signature（デフォルト）
criteria=leastcommon // 出現頻度とカウント数が低い Signature

_sourceCategory= "Labs/AWS/GuardDuty_V8"
| logreduce by _sourceHost limit=5,criteria=mostcommon

ユースケース

使える場面は、冒頭でもお話しした大量のログをまとめて調査範囲を絞るということですが、具体的にどんな時に、どうやって、どこまで絞るべきかについてご説明します。単純に大量のログをグループ化できる機能だと言って、_sourceCategory=Labs/AWS/GuardDuty_V3 | logreduce などの非常に抽象的な検索をしてしまっては、各 Signature が膨大な量になるだけです。そのため、parse と where、if などの演算子を使用してクエリの段階でスコープを絞り込めると調査の効率も向上します。

下記に例を記載します。出力されるログの量に応じてクエリ時に指定するスコープを絞る条件を増やしてください。

例１）AWS リージョン、アカウントレベル（環境レベル）で絞る

_sourceCategory=Labs/AWS/GuardDuty_V3
| parse "accountId\":\"*\"" as accountId, "region\":\"*\"" as region
| where !isNull(accountId AND region)
| where accountId = "prod" AND region = "us-east-1"
| logreduce

こちらは、２行目で accountId、region をパースしており、３行目でフィールドの Null チェックをして弾いています。さらに４行目では、本番環境であることと、バージニア北部のリージョンを指定しています。環境や、リージョンごとに調査したいログを見る場合、特にマルチリージョンやマイクロコンポーネント化していると複数の Signature が大量に出力されるので、クエリで限定的に絞り込むことで調査の効率が上がります。

例２）キーワード検索を使用する

_sourceCategory=Labs/Apache/* error
| parse "mod_log_sql: * connection error" as db_connection_error
| where !isNull(db_connection_error)
| where db_connection_error = "database"
| logreduce

こちらは、１行目に error というキーワードで絞ったログに対して、２、３行目でパースと Null チェックを行い、４行目で、database という文字列が含まれるログに絞り込んでいます。こうすることで、エラーログのなかでも、データベースとの接続が正常に行えなかったログを検索できます。

LogCompare

こちらは、過去データとの比較ができるということで、以前は発生していなかったログや、過去と比較して異常に増えているログなどの発見に貢献できます。具体的には、後述の TimeShift というもので、ベースライン（過去のログデータ群）とターゲット（現在のログデータ群）を比較してロググループの出現率を含めて Signature を出力します。そのため、障害発生前のログで出力されるような新たなログを発見することが出来、根本原因のトラブルシューティングが可能です。

構文

| logcompare timeshift <time> [baseline (<baseline query>)]

timeshift

ベースライン（過去のログデータ群の起点）を決定します。

_sourceCategory=Labs/Apache/* error
| logcompare timeshift -24h

[baseline ()]

ターゲットと、ベースラインのクエリを比較できます。

具体的には、| logcompare timeshift -N 以前のクエリ結果とbaseline()に記述するクエリ結果の過去と現在のログ比較します。

_sourceHost=cluster-1
| logcompare timeshift -0s baseline(_sourceHost=cluster-2)

ユースケース

LogReduce をベースとして拡張された機能なので、parse と where、if などの演算子を使用するということは同じでして、基本的に LogReduce のユースケースでお伝えした方法を利用しつつ、ここでご紹介する LogCompare の特徴である過去データとの比較という観点で組み合わせてお使いください。

例１）新たに出現したログのみを表示させる。

_sourceCategory=Labs/AWS/GuardDuty_V3
| parse "accountId\":\"*\"" as accountId, "region\":\"*\"" as region
| where !isNull(accountId AND region)
| where accountId = "prod" AND region = "us-east-1"
| logcompare timeshift -24h
| where (_isNew)

３行目の where (_isNew) は、LogCompare の出力結果に対して、新たに出現したログのみを表示させるように条件を指定しています。

例２）エラーログなど、重要情報の推移を表示する

_sourceCategory=Labs/Apache/* error
| parse "GET * " as GET_Object
| where !isNull(GET_Object)
| logcompare timeshift -15m

エラーや、重要度の高いログメッセージなどの増加しているログ数も、このキーワード検索を使用して調査可能です。

まとめ

LogReduce、LogCompare は、AI 基盤の検索機能なのですが、検索結果が明確な答えを出してくれるわけではないため、クエリ文の方を明確にしてユーザがどのログを見たいか明確にする必要があると思います。また、場合によっては count 演算子や、transpose 演算子などで集計した方が分かりやすこともあります。例えば、この記事を書いている中で、LogCompare を使用して HTTP ステータスコードで WEB ページのキャッシュ率を出力させようかと考えましたが、これこそ count + transpose + _timeslice 演算子を組み合わせた方が正確な答えを返してくれます。限定的な情報を得るための手段として、LogReduce は多くのログの中にある重要な情報を調査したり、定期的な分析による調査のための機能として使用して、LogCompare はアラートをトリガーとしての根本原因のトラブルシューティングの為に過去データと比較して使用していただくのがよいのではないかと思います。ということで、僕自身もっと深堀してみたい機能なので今後も本記事を更新していければと思います。